A Web service is a software module identified by a Uniform Resource Identifier (URI), whose interfaces and bindings are capable of being defined, described and discovered. Web services support direct interactions with other software applications using XML based messages via various communication protocols.
Web services are modular software components wrapped inside a specific set of Internet communications protocols. These software components can be run over the Internet and can communicate with other components automatically without human intervention. Advantageously, Web services can be used on an Intranet inside a firewall, or out across the greater Internet. A Web service itself is a software module delivered over the Internet or an intranet via XML messaging. A given modular software component can be built in a variety of ways including, most notably, but not exclusively, using Java.
In order for a computer or application to use a Web service, the computer or application needs be able to find a service description of the Web service and then bind to the service description. To accomplish this finding and binding, there are three key parts to the Web services architecture: a service provider, a service registry and a service requester. Together, the three key parts perform three operations on a Web service: publish, find and bind.
The publish operation makes information about the Web service available so that the information can be found and used. In other words, the publish operation makes the service description publicly available. The find operation is used by a service requester to discover the Web service. The find operation is the way in which the computer or application searches for Web services. The find operation occurs when the service requester retrieves a service description directly or queries the registry for the type of service required. The find operation may be involved in two different lifecycle phases for the service requester (or service provider): at design time in order to retrieve the Web service's interface description for program development, and at runtime in order to retrieve the service's binding and location descriptions for invocation.
The bind operation allows the service to be used by the computer or application requesting the service. More particularly, the bind operation allows the application to understand what the Web service is, where the Web service is located and how to link to the Web service. The bind operation occurs when the service requester invokes or initiates an interaction with the Web service at runtime using binding details in the service description to locate, contact and invoke the Web service.
A mechanism for publishing and finding service descriptions is provided by Universal Description, Discovery and Integration (UDDI). UDDI is an XML-based registry for businesses worldwide to list themselves on the Internet. The ultimate goal of UDDI is to streamline online transactions by enabling companies to find one another on the World Wide Web and make systems that are interoperable for e-commerce. UDDI allows businesses to list themselves by name, product, location or the Web service offered.
The UDDI data entities provide support for defining both business and service information. There are four primary data types in a UDDI registry: businessEntity, businessService, bindingTemplate and tModel. The businessEntity provides information about a business and can contain one or more businessServices. The business is the Web service provider. The technical and business descriptions for a Web service are defined in a businessService and the bindingTemplates of the businessService. The bindingTemplate includes technical details necessary to invoke a Web service. These technical details include Uniform Resource Locators (URLs, e.g., Web addresses), information about method names, argument types and so on. Each bindingTemplate contains a reference to one or more tModels. A tModel is used to define the technical specification for a service.
The Web Services Description Language (WSDL) is an XML-based language for describing Web services. A WSDL service description contains an abstract definition for a set of operations and messages, a concrete protocol binding for these operations and messages and a network endpoint specification for the binding.
WSDL is derived from the Simple Object Access Protocol (SOAP) developed by Microsoft and the Network Accessible Service Specification Language (NASSL) developed by IBM.
The service description information defined in WSDL is complementary to the information found in a UDDI registry. UDDI provides support for many different types of service descriptions. As a result, UDDI has no direct support for WSDL or any other service description mechanism.
While WSDL is a standard for describing services at a functional level and UDDI is a standard for describing services from a more business-centric perspective, it has been recognized that there is a need for the ability to tie together, at the point of offering of the service, these various sources of information. Ideally, these various sources of information should be tied together in a manner which is both simple to create and simple to utilize. Web Services Inspection Language (WSIL) is known to address this need by defining an XML grammar that facilitates the aggregation of references to different types of service description documents and provides a well-defined pattern of usage for instances of this grammar. By doing this, WSIL provides a means by which to inspect sites for service offerings.
The WSIL specification (see <<http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html>>provides an XML format for assisting in the inspection of a site for available services and a collection of rules for how inspection-related information should be made available for consumption. Notably, the specification may be more widely known as a specification for Web Services Inspection or, simply, “WS-I”. A WSIL (or WS-I) document provides a means for aggregating references to pre-existing service description (inspection) documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering of the service as well as through references that may be placed within a content medium.
As discussed hereinbefore, a service provider may publish a WSDL document to describe the details of the Web service provided such that an application requiring that Web service may discover the service provider as a provider of a service required by the application. The application learns how to talk to the Web service through the WSDL document offered by the service provider. In general, the WSDL document only describes the Web service itself, the WSDL document does not contain other information such as a URL of the WSDL document or the contact information for the business providing the Web service. This information about the WSDL document may be called the metadata of the WSDL document.
In a situation wherein the application requires a Web service more than once, metadata related to the WSDL document that describes the Web service may be important to the application well into the life of the application. It is preferable, then, that the metadata be maintained through startup and shut down of the application.
The metadata can be maintained by a database system. However, maintaining WSDL-related metadata may be considered a computationally intensive task for the application to perform along with the task for which the application was originally designed. Furthermore, the application may be considered to be tied to the platform on which the database system is running.
Another approach to maintaining the metadata is to use Java object serialization. However, Java object serialization has several disadvantages including low readability, low porting ability (the data cannot be easily retrieved by applications written in other languages) and the data may no longer be usable if the source of the Java object changes.
Clearly then, a need exists for a programming language-independent manner in which metadata related to published descriptions of Web services may be stored without the computational intensity of typical database systems.